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FOREWORD

This Indian Standard which is identical with lSO/IEC 12119 : 1994 `Information technologySoftware for packages - Quality requirements and testing' issued jointly by the International Organization Standardization (ISO) and International Electrotechnical Commission (IEC) was adopted by the Bureau of Indian Standards on the recommendation of Software Systems, Languages and Methodologies Sectional Committee (LTD 33) and approval of the Electronics and Telecommunication Division Council. The text of the ISOIIEC standard ~has been approved as suitable for publication as Indian Standard without deviations. Certain conventions are, however, not identical to those used in Indian Standards. Attention is particularly drawn to the following: Wherever the words `International read as `Indian Standard'. CROSS REFERENCES The concerned technical in this adopted standard standard: committee has reviewed the provisions of the following standards referred and has decided that these are acceptable for use in conjunction with this Standard' appear referring to this standard, they should be

ISO/IEC Guide 22 : 1996 General criteria for supplier's ISO/IEC Guide 23 : 1982 Methods of indicating systems ISO/IEC Guide 25 : !990 laboratories General requirements

declaration

of conformity for third-party certification

conformity

with standards

of the correspondence

of certification

and testing

ISO/IEC Guide 28 : 1982 General rules for a model third-party

certification

system for products certification schemes

ISO/IEC Guide 44 : 1985 General rules for IS0 or IEC international for products ISO/IEC Guide 58 : 1993 Calibration and testing requirements for operation and recognition laboratory

third-party

accreditation

systems

-

General

ISO/IEC Guide 60 : 1994 ISO/IEC Code of good practice for conformity ISO/IEC Guide 65 : 1996 General requirements
NOTE ISO/IEC Guide 16

assessment systems

for bodies operating

product certification

: 1978 has been now replaced by ISOAEC Guide 60 : 1994 and ISOAEC Guide 40 : 1983 has

been now replaced by ISOAEC Guide 65 : 1996.
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Indian Standard

INFORMATION TECHNOLOGY - SOFTWARE PACKAGES-QUALITY REQUIREMENTS AND TmESTING

1 Scope
This International Standard is applicable to software packages. Examples are text processors, spreadsheets, data base programs, graphics packages, programs for technical or scientific functions, and utility programs. It establishes requirements requirements); for software packages (quality

b) certification bodies which may wish to establish a third-party certification scheme (international, regional or national) [ISO/IEC Guides 16, 28 and 441; c) testing laboratories which will have to follow the instructions for testing when testing for a certificate or a mark of conformity [ISO/IECGuide 251; d) accreditation bodies for accrediting tion bodies and testing laboratories Guides 40 and 581; certifica[ISO/IEC

instructions on how to test a software package against these requirements (instructions for testing, in particular for third party testing). It deals only with software packages as offered and delivered. It does not deal with their production process (including activities and intermediate products, e.g. specifications). The quality system of a supplier is outside the scope of this International Standard.
NOTE - Some software critical software. needs additional requirements, e.g. safety-

e) auditors of testing laboratories when assessing their competence [ISO/IEC Guide 581;

f)

buyers who may 1) compare their requirements scribed here; with those de-

2) compare the requirements for the intended work task with the information in product descriptions of existing products; 3) look for certified products; otherwise if the requirements are

The intended clude a)

users of this International

Standard

in-

suppliers

when requirements for a software

4) check met;

1) specifying package; 2) 3) designing assessing

9)

users who may profit from better products.

a form to describe products; their own products; of conformity [IS01

2

Definitions

4) issuing declarations IEC Guide 221;

For the purposes of this International Standard, the following definitions apply. Definitions from other standards used in this International Standard are reproduced in annex A for convenient reference.

5) applying for certificates or marks of conformity [ISO/IEC Guide 231;
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2.1 function: The implementation of an algorithm in the program with which the user or the program can perform part or all of a work task. NOTES
1

2.7 maintenance: That part of system maintenance (see A.5.2) which is concerned with modifying a software package.

A function does not need to be callable by the user (e.g. automatic

3

Quality requirements

backup or saving of data).

Subclauses 3.1 to 3.3 contain
2 The notion of a function here is narrower than that used in IS0 2382-14:1978 (in the definitions of failure, fault, maintenance and reliability), but wider than those defined in IS0 2382-2 and IS0 2382-i 5.

- the requirement,that each software package has a product description and user documentation; requirements for the product description, In particular, there is a requirement that it shall contain specified information and that all its statements shall be testable and correct; requirements for the user documentation;

2.2 requ~irements document: A document containing any combination of recommendations, requirements or regulations to be met by a software package.
NOTE - Examples are a technical or ergonomic standard, a requirements list (or model requirements specification) from a group (e.g. a market sector, technical or user association), a law or a decree.

2.3 product description: A document stating properties of a software package, with the main purpose of helping potential buyers in the evaluation of the suitability for themselves of the product before purchasing it.
NOTE -This term is more specific than the term "system description" in ISO/IEC 2382-20:1990. The purpose of the product description includes that of the "cover information" in IS0 9127. The product description is not a specification; lt serves a different purpose.

requirements for the programs and for data, if any, included in the software package. NOTES
1 The requirements on user documentation, programs and data contain many general requirements (independent from what may be promised in a product description), but they do not include all the properties that usem may desire. 2 Certain properties, for example "understandability" and "ease of

2.4 user documentation: The complete set of documents, available in printed or non-printed form, that is provided for the application of the product and also is an integral part of the product. 2.5 package documentation: The product description and the user documentation. 2.6 test case: A documented instruction for the tester that specifies how a function or a combination of functions shall or should be tested. A test case in. eludes detailed information on the following issues: the test objective; the functions to be tested;

overview" of the user documentation and of the program messages, are admittedly required in the view of the user. However, due to the diffiiulty of testing for them with clear-cut and reproducible results these are formulated currently as recommendations only. 3 The requirements in 3.1 to 3.3 are arranged in the same order as

the characterfstfcswhich appear in ISO/iEC 9126.

A software package conforms to this International Standard if it complies with all the requirements`in 3.1 to 3.3. The recommendations (indicated by the use of the verbal form "should") are optional.
NOTE 4 - Conformity of a product to the requirements in 3.1 to 3.3 may be difficult or impossible to prove. However, a test (including review of documents) according to clause 4 is deemed sufficient to provide the confidence required for a certificate of conformity according to ISOAEC Guide 2. No formal proof is needed.

- the testing environment and other conditions (configuration details~and preparatory work); the test data; the procedure; the expected behaviour of the system.

3.1 Product description
Each software package shall have a product description.

2
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The product description defines the product. It is a part of the package documentation of the product. It provides information on the user documentation, the programs and, if any, the data. The main purposes of the product description are

c) Supplier The product description shall contain address of at least one supplier.
NOTE -The

the name and

name and address need not be printed; the rubber stamp

of a dealer is sufficient.

to help the user or potential buyer in their evaluation of the suitability of the product for themselves. To this exient it isalso salts information; to serve as a basis for testing (see clause 4). for people

d) Work task The product description shall identify the intended work tasks that can be performed with the product. e) Conformity to requirements documents

The product description shall be available interested in the product. 3.1.1 General reqbirements on contents

The product description may refer to requirements documents to which the product conforms, in which case the relevant editions shall be identified. f) Required system The required system (hardware, software and their configuration) for putting the product into use shall be specified, including manufacturer names and type identifiers of all parts, for example processing unit including co-processors;

The product description should be sufficiently understandable, complete and easy to overview for helping potential buyers in the evaluation of the suitability for themselves of the product before purchasing it. It shall be free from internal inconsistencies. should have the same meaning~everywhere. The statements of the product testable and correct.
NOTE - This requirement extends

Each term

description

shall be

main memory size; types and sizes of peripheral extension cards; storage;

to the statements

in external

requirements documents invoked, if spy (see 3.1.2 e).

~-

The following subclauses 3.1.2 to 3.1.8 specify what the product description shall or should include. It may include additional statements on the product. 3.1.2 Identifications and indications

input and output equipment; network environment: system software and other software.

a) Identification

of the product description

The product description shall possess a unique document identification. It may be named differently from "product description", for example: "Functional Description", "Product Information", "Product Sheet". b) identification of the product

Different required systems may be specified, e.g. for different work tasks, different boundary values or different efficiency requirements. The statement "(or any other . . . . if compatible)" may appear in a product description if previously a particular hardware or software product has been identified. The statement "or an updated version if compatible" may appear if previcusly a version of a product has been identified. The statement "from version X to at least version Y" may appear; "from version x" shall not appear.
NOTE - A statement "`from version x" could later become false by the appearance of a version X+3 with which the software package would fail to operate.

The product description shall identify the product. The product identification shall have at least the product name and a version or date. If there are two or more variants mentioned in the product description, then each variant shall have at least the product name, a variant name and a version or date.

3
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g) Interfaces

to other products makes reference to interthe interfaces or products

NOTE - Not everi user-callable functfon need be mentioned, and not every detail on how a function is called need be given.

If the product description faces to other products, shall be identified. h) Items to be delivered

b) Boundary values If the usage of the product is limited by product specific boundary values, these shall be provided. Examples are minimum or maximum values; lengths of keys; maximum number of records in a file; maximum number of searchcriteria; minimum sample size.

Every physical component of the supplied product shall be identified, in particular all printed documents and all data media. The form of the supplied programs shall be stated, e.g. source programs, object modules or load modules.
NOTE - Media formats (e.g. diskette formats) need not be indicated because the set of possible formats is determined by the required

-

system (see 3.1.2 f).

i) Installation It shall be stated whether or not the product tion can be carried out by the user. installa-

0 SuPPo~
It shall be stated whether the product is offered. k) Maintenance It shall be stated whether or not maintenance is offered. If maintenance is offered, it shall be stated what is specifically included. 3.1.3 Statements on functionality or not support for operating

In the case when it is not possible to provide fixed boundary values (when, for example, they depend upon the application type or upon the input data), then the limitations shall be stated. Permissible combinations of values may be provided~and reference shall be made to more specific information in the user documentation. c) Security The product description should include information on means, if provided, for preventing unauthorized access, whether accidental or deliberate, to programs and data. 3.1.4 Statements on reliability shall include information on

The product description data saving procedures.

a) Overview

of functions
NOTE - It is sufficient to state, for example, that backup is possible by functions of the operating system.

The product description shall provide an overview of the user-callable functions of the product, the necessary data and the facilities offered. It shall be clearly stated for each function mentioned (especially for an option or variant) whether it is a part of the product; fully described in the

Additional product properties should be described that ensure the functional capability of the product. Examples are checks whether input is plausible; of a

of a product extension product description; of a product extension uct description; of a supplement without

protection user mistake; -

against serious consequences

error recovery.

referenced

in the prod-

-

guarantee.

4
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3.1.5

Statements

on usability

e) Efficiency of usage and user satisfaction The product description may include cy of usage and user satisfaction. data on efficien-

a) User interface The type of user interface shall be named, for example, command line, menu, windows, function key, help function. b) Required knowledge of the

NOTE - Such data may follow the guidance of IS0 9241-l 1.

3.1.6

Statements

on efficiency

Specific knowledge required for the application product shall be specified. Examples are knowledge knowledge knowledge of a technical area; system;

The product description may include data on the time behavior of the product such as response times and throughput rates for given functions under stated conditions (for example the system configurations and load profiles). 3.1.7 Statements on maintainability may contain statements on

of an operating obtainable

by special training;

The product description maintainability. 3.1.8 Statements

knowledge of a language other than that in which the product description is written. All the natural languages of the user documentation and of the user interface (including error messages and visible data) shall be stated, both of the software package itself and of all other products mentioned in the product description.
NOTE -This requirement exceeds the one in IS0 9127:1968, 6.1.7,

on portability may contain statements on

The product -portability.

description

3.2 User documentation
3.2.1 Completeness

where the mention of the languages used is optional.

c) Adaptation

to the user's needs

If the product can be adapted by the user, then the tools for this adaptation and the conditions of their use shall be identified. Examples are changing changing of parameters; of algorithms to function for computation; keys. infringement

The user documentation shall contain the information necessary for the use of the product. All the functions stated in the product description and all user-callable functions in the program shall be completely described in the user documentation. All boundary values given in the product description shall be repeated in the user documentation. If installation can be carried out by the user, the user documentation shall include an installation manual containing all necessary information (see 3.3.1 a). The installation manual should state the minimum and maximum sizes of the files once installed. If maintenance can be carried out by the user, the user documentation shall include a program maintenance manual containing all the information that is necessary for the kind of maintenance concerned. 3.2.2 Correctness

assignments

d) Protection

against copyright

If technical protection can hamper usability, stated. Examples are technical

against copyright infringement then this protection shall be

protection

against copying;

programmed interactive

expiry dates for usage; All information in the user documentationshall be correct. In addition, its presentation should be free from ambiguities and errors.

reminders to pay for copies.

5
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3.2.3

Consistency

c) Correctness The programs and data shall correspond to all the statements in the product description and the user documentation. The functions shall be executed in a correct manner ~for the work task. In particular, programs and data shall comply with all the requirements in any requirements document referenced by the product description. d) Consistency

The documents of the user documentation shall be free from contradiction within themselves, with each other and with the product description. Each term should have the same meaning everywhere.
NOTE-Consistency with programs and data is dealt with in 3.3.1 .d.

3.2.4

Understandability

The user documentation should be understandable by the user population that normally performs the stated work task, for example by using an appropriate selection of terms, graphical exhibits, detailed explanations and by referencing useful information sources. 3.2.5 Ease of overview

The programs and data shall be free from contradictions withinthemselves and with the product description and the user documentation. Each term should have the same meaning everywhere. The control of the `program operation by the user and the program behaviour (for example, messages, input screen formats and printed reports) should be uniformly structured. 3.3.2 Reliability

The user documentation should be easy to overview so that relationships are recognizable. Every document an index. should have a table of contents and

If a document is. not provided in printed form the procedure for printing it should be indicated.

The system, comprising hardware, required software and those programs that belong to the product, shall not fall into such a state that the user cannot control it, and shall neither corrupt nor lose data. This requirement shall even be met in the case that up to the specified limits; beyond

3.3 Programs and data 3.3.1 Functionality attempts are made to exploit capacity the specified limits; capacity is exploited

a) Installation If installation can be carried out by the user, it shall be possible to install the programs successfully by following the information in the installation manual. Each of the required systems given in the product description shall be sufficient for installing the programs. Following installation it shall be recognizable whether or not the programs can function, for example using supplied test cases or by self-testing with corresponding messages. b) Presence of functions

an incorrect input is made by the user or from another of the programs listed in the product description; explicit instructions are violated. in the user~documentation

Only those possibilities for hardware and operating system interruption that cannot be caught by any program (for example, the key or combination of keys for system operation reset) are excluded. The programs shall recognize violations of syntactic conditions for input. In the case where a program recognizes an input as erroneous or as undefined, it shall not process this as permissible input. 3.3.3 Usability based to in-

All functions mentioned in the user documentation shall be executable in the form given in the user documentation with the corresponding facilities, properties and data, and within the boundary values given there.
NOTE - Since all functions mentioned in the product description shall also appear in the user documentation, executable. it follows that they too shall be

With respect to usability, parties to agreements on this International Standard are encouraged

1s 14639 : 1998 ISO/IEC 12119 : 1994

vestigate the possibility of applying the most recent editions of standards in the IS0 9241 series.
Note - In particular-parts considered. 10 and 13 of the IS0 9241 series should be

-

numeric fields are right-aligned; are ar-

in tables, decimal points or commas ranged in the same vertical line; field limits are recognizable; is obligatory,

a) Understandability The questions, messages should be understandable, by an adequate by graphical by provision and results of the programs for example, of terms;

fields, the use of which ognizable as such;

are rec-

selection

identified input failures are immediately lighted in the input screen format;

high-

representations; of background information; the user's attention is directed to a change screen content by a visual or audible sign. c) Operability The execution -of functions that have serious consequences shall be reversible, or the programs shall give a clear warning of the consequences and request confirmation before executing the command. In particular, erasure and overwriting of data, as well as interruptions of a lengthy processing operation, have serious consequences. If documenting text is offered in the dialogue, the user should be able to access subclauses of the text in a direct manner, for example, by selection from a displayed table of contents and by a search function based on keywords. 3.3.4 Efficiency in

by the explanations

of a help function.

Error messages shall offer detailed information explaining the cause or the correction of the corresponding usage errors (for example by a reference to an item in the user documentatron). b) Ease of overview Each data medium shall bear the product identification and, if there is more than one medium, a distinguishing number or text. For the user, when working with the programs it shall always be possible to find out which function is being executed. The programs should provide information to the user in such a form that it is easily visible and easy to read. The user should be guided by appropriate coding and grouping of the information. Where necessary, the programs should alert the user. Messages from the programs should be so designed that the user can easily differentiate them by type, for example, acknowledgement; queries from programs; warnings; error messages.

Nothing is required. However, statements on efficiency in the product description shall be conformed to. 3.3.5 Maintainability

Nothing is required. However, statements on maintainability in the product description shall be conformed to. 3.3.6 Portability

Nothing is required. However, statements on portability in the product description shall be conformed to.

4

Instructions

for testing

Input screen formats, reports and other inputs and outputs should be designed to be clear and easy to overview. Possibilities for this include alphanumeric fields are left-aligned;

The instructions in 4.1 to 4.5 specify how a product shall be tested against the quality requirements. They include both testing for properties required from all conforming products and testing for properties promised by the product description.' They include

7
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both testing by inspection of documents and blackbox testing of programs and data. These instructions describe functional testing (blackbox testing). Structural testing is not included because it would.require the availability of the source code. Only the product in its required systems is tested. The ergonomic evaluation at the computer workplace is not considered in this International Standard. NOTES
1

4.2

Testing

aclivities

The product description, user documentation, programs and any data to be delivered as parts of the software package - shall be tested for compliance~with the requirements in clause 3, and - should be tested for compliance with the recommendations in clause 3. The test objectives shall be derived from, and include all, the requirements in clause 3 (completeness, consistency etc.). If other products are mentioned in the product description, these other products need only be tested for the claims made in the product description of the product under test. Details in the product description, in the user documentation, in functions or in data of the product do not need to be tested if according to the judgement of the tester - they have negligible influence ability for the named work task, and on the syit-

These instructions are primarily aimed at third party testing

according to some certification scheme (see clause I, item c). During production it may be cheaper and more effective io use structurai testing. 2 Clause 4 does not contain requirements on software packages (all

these are contained in clause 3). A software package may conform without having been tested according to clause 4, and such a test may fail to discover an existing nonconformity. 3 As the required system is determined by the product description, any nonconformity of the product on the required system is treated as a nonconformity of the product. 4 A certification scheme may make testing against recommen-

dations optional. 5 Guidance on ergonomic evaluation is contained in IS0 9241-l 1.

- they can be tested in principle but not with justifiable expenditure. * Such details which are not tested shall be mentioned in the test records and in the test report. The reasons for not testing them shall be documented in the test records.

4.1
4.1.1

Test

pre-requisites
of product items

Presence

4.2.1 For testing a software package all items to be delivered (see 3.1.2 h) as well as the requirements documents identified in the product description (see 3.1.2 e) shall be present. 4.1.2 Presence of system constituents

Product

description

The fulfilment of the requirements in clause 3 shall be tested, and the fulfilment of the recommendations in clause 3 should be tested. 4.2.2 User documentation

For testing a software package it is required that the constituent parts of all the computer systems as named in the product description are available. 4.1.3 Training

The fulfilment of the requirements in clause 3 shall be tested, and the fulfilment of the recommendations in clause 3 should be tested. 4.2.3 Programs and data

If training is mentioned in the product description, the tester shall have access to the training material and the training program.

The fulfilment_of the requirements in clause 3 shall be tested, and the fulfilment of the recommendations in clause 3 should be tested.

6
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The programs shall be tested in all the computer systems that are named in the product description. If there are several program variants, each shall be tested. Functions that, according to the product desciiption and user documentation, are identical in a number of variants may be tested each in one vari8nt. The programs and the data supplied with them shall Abetested using test cases constructed on the basis of the product description and the user documentation. Further material (for example, source programs) need not be considered unless the testing of statements in the product description or user documentation makes this necessary. The test cases shall be constructed methodically and systematically.
NOTE - Methodical random testing is permitted.

4.3

Test

records

The records for each test shall contain sufficient information to permit the repetition of the test [lSO/lEC Guide 251. They shall include - a test plan or test specification containing test cases (each test case stating its objectives, see 2.6); - all the results associated with the test cases, including all the failures occurring during the test; the identity of personnel involved in testing.

4.4

Test report

The objects and the results of the test (as recorded in the test records) shall be summarized in a test report. The test report shall have the following structure: 1 Product identification

If examples are given in the user documentation they shall be used as test cases, but testing shall not be restricted to these examples. Test cases provided by the supplier of the software package may be used but testing shall not be restricted to these test cases. a) Jnstallation If, according to the pioduct description, can be carried out by the user, it shall be the programs can be installed and successful installation as described in the manual. installation tested that tested for installation

2 Computer systems used for testing (hardware, software and their configuration) 3 Documents used (with their identifications)

4 Results of the test of the product description, user dpcumentation, programs and data 5 List of the non-conformities to.requirements

Otherwise it shall be ensured that the hardware and software environment of the installed programs corresponds to the statements in the product desc:ip:ion for the computer system under consideration. b) Program execution The test cases shall cover all functions described in the product description and user documentation and they shall take into account combinations of functions that are representative for the work task. The programs shall be tested ,for all boundary values (according 40 product description and user documentation) in the required systems for which these values apply. Input or command sequences that are explicitly deprecated or declared as forbidden in the user documentation (see 3.3.2) shall be used in the testing.

6 Eitr.er a list of the non-conformities to recommendations, or a list of the recommendations that were not followed, or a statement that the product was not tested for conformity to recommendations 7 Date of the termination of the test

Chapter 4 of the test report (Results of the test) shall contain a statement corresponding to each headline of 3.1 to 4.2. In addition to the statement that the product was not tested for conformity with recommendations, chapter 6 of the test report may provide a list of observed nonconformities to recommendations. The identification of the test report (testing laboratory, product identification, date of the test report) and the total number of its pages shall appear on each page of the test report.

9
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The test report shall include a statement to the effect that the test results relate only to the items tested; a statement that the test report shall not be reproduced except in full without the written approval of the testing laboratory [ISO/IEC Guide 251. The test report should comply with the provisions test reports in ISO/IEC Guide 25. for

4.5 Follow up test
When a product, which has already been tested, is tested again (taking into consideration the previous test), then all changed parts in the documents, functions and data shall be tested as if it were a new product; all unchanged parts that are expected to be influenced by the changed parts or by changes in a required system (according to the specialized knowledge of the tester) shall be tested as if it were a new product; all ot.her parts samples. shall at least be tested by

10
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Annex A
(informative)

Definitions from other standards
For easy reference, definitions are quoted here for some terms used in this International Standard but defined in other standards. At the time of publication, the editions indicated were valid, and the definitions quoted from them were used or considered. A.1.9 configuration: The manner in which the hardware and software of an information processing system are organized and interconnected. [ISO/IEC 2382-l : 19931

A.2 Characteristics A.1 General terms

of a product

A.l.l software: All or part of the programs, procedures, rules; and any associated documentation of an information processing system. [ISO/IEC 23821:1993, without the Note] A-1.2 software package: A complete and documented set of programs supplied to several users for a generic application or function. [ISO/IEC 238220:1990, without the Note] A.l.3 system software: Application-independent software that supports the running of application softWare. [ISO/IEC 2382-20:1990] A.1.4 utility routine, utility program: A routine [A computer program] that orovides general, frequently needed services for computer users and service personnel. [ISO X382-7:1989, without the examples] A.1.5 functional unit: An entity of hardware or software, or both, capable of accomplishing a specified purpose. [ISOIIEC 2382-l :1993] A.1.6 (computer) program: A syntactic unit that conforms to the rules of a particular programming language and that is composed of declarations and statements or instructions needed to solve a certain function, task, or problem. [ISO/IEC 2382-l :1993] A.1.7 interface: A shared boundary between two functional units, defined by functional characteristics, common physical interconnection characteristics, signal characteristics, and other characteristics, as appropriate. [ISO 2382-9:1984, without the Note] A.1.8 user interface: An interface that enable? information to be passed between a human user an@ hardware or software components of a comptiter system. [ANSI/IEEE Std 610.12-l 9901

A.2.1 functionality: A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs. [ISO/IEC 9126:1991, without the Notes] A.2.2 reliability: A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time. [ISO/IEC 9126:1991, without the Notes] A.2.3 usability: A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users. [lSO/IEC 9126:1991, without the Notes] A.2.4 efficiency: A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions. [ISO/IEC 9126:1991, without the Note] A.2.5 maintainability: A set of attributes that bear on the effort needed to make specified modifications. [ISO/IEC 9126:1991, without the Note] A.2.6 portability: A set of attributes that bear on the ability of software to be transferred from one environment to another. [tSO/IEC 9126:1991, without the Note]

A.3 Data
A.3.1 data: A reinterpretable -representation of information in a formalized manner suitable for communication, interpretation, or processing. [ISO/IEC 23821 :1993] A.3.2 data medium: A material in or on which data can be recorded and from which data can be retrieved. [ISO/IEC 2382-l :1993]

11
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A.4 Testing
A.4.1 test: Technical operation that consists of the determination of one or more characteristics of a given product, process or service according to a specified procedure. [ISO/IEC Guide 2:1991]

A.5 Other terms
A.5.1 program maintenance manual: A document that provides all the information necessary to maintain a program. [ISO/IEC 2382-20:1990] system maintenance: The modification of a system to correct -faults, to improve performance, or to adapt the system to a changed environment or changed requirements. [ISO/IEC 2382-20:1990] A.5.2, A.5.3 work task: An intended outcome of the work system. [ISO 638519811 work system: The work system comprises a combination of people and work equipment, acting together in the work process, to perform the -work task, at the work space, in the &r-k environment, under the conditions imposed by the work task. [ISO 6385:1981] A.5.4

A.4.2 test data: The data used for a check problem. [ISO 2382-8: 19861 A.4.3 check problem: A problem with a known solution used to determine whether a functional unit is operating correctly. [ISO 2382-8:1986]

Specified technical procedure for performing a test. [tSO/IEC Guide 2:1991]
A.4.4 test method: A.45 test plan, system test and evaluation plan:

A plan that establishes detailed requirements, criteria, general methodology, responsibilities, and general planning for test and evaluation of a system. [ISOIIEC 2382-20:1990]
A.4.6 test report: Document that presents test. results and other information relevant to a test. [ISO/IEC Guide 2:1991]
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Annex B (informative) Example of a product
The following example describes, in accordance with this International Standard, a simple imaginary software package, in order to show information that shall be present in every product description. Product description sheet FCREatWORK

description
- FlREatWORK runs on a Quince Hardcore 119xi personal computer (and on compatible computers) with at least 1 MB main memory and a 90 mm (35 in) or 130 mm (525 in) diskette drive for at least 720 KB. It does not need a hard disk. It supports a serial or parallel Mini-RAT mouse (or any other mouse, if compatible), but no mouse is required; FlREatWORK needs a graphics card: Hercules DeLuxe or PowerEGA 16+ (or any other card, if compatible); - FIREatWORK runs under B.1.T.S 1.01 or Gnome 3.0 (or any operating system compatible with one of these two).

Version

2.6

FIREatWORK - screen saver and password protection The program FIREatWORK will save your screen by displaying a stunning - and on Red-Green-Blue screens colourful - firework while you are not working with your computer. If you enter a password you will be warned if anyone has tampered with your computer in your absence. FlREatWORK is installed in the memory. It will activate itself when you don't press any key and don't move the mouse (if any) for some (adjustable) time. It will stop as soon as you press any key or move the mouse. However, if you define a password, FlREatWORK will wait for that password to be typed. You can define your favourite settings for - the time FlREatWORK will wait before activating itself (1 to 999 minutes, or never); - the number of fireworks that will explode together (1 to 19). For this, FlREatWORK will use line dialog or a window (as your operating system does for changing system date and time). In the same way you may define a password (6 to 45 characters). Then, if FlREatWORK stops upon typing an arbitrary character or does not stop upon typing your password, someone has interrupted FIREatWORK (e.g. by switching off the power) and restarted it without a password or with a different one. You may produce backup copies of the program and .the setting by means of your operating system. The password is not-saved. Some technical details: The packet consists of the program (load module) eon one diskette and a documentation booklet which includes the installation guide. Important for you: - You don't need any special install or use FIREatWORK. knowledge to

When ordering FlREatWORK please tell us - whether you want the variant for B.1.T.S or the one for Gnome; - whether you want FlREatWORK on a 90 mm (3,5 in) diskette or on a 130 mm (5,25 in) diskette.

Program messages and documentation written in English.

are

FlREatWORK fully complies with ISO/IEC 12119: 1994 information technology - Software packages - Qualify requirements and testing. Neither support for operating the product nor maintenance is offered. Where do you get FIREatWORK: PyroManiac Klaus P Schmidt Ltd 33 Bell Street Bergheim, SU 53844 Telephone (022) 845 3902
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